Modular distributed mobile data applications

ABSTRACT

Computer-implemented system and methods for deploying a distributed client-server system, enabling developers to rapidly create and deploy read-write distributed data interfaces for host database systems. The disclosed system is especially advantageous for mobile clients as connection to the server environment can be intermittent without unduly impeding local (disconnected) operations. One important aspect of the invention is an incremental process for executing an application servo in a client device. This process includes building and incrementally maintaining a logical context tree in which each node expresses a complete current state of the execution process.

RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.10/006,200, filed Dec. 4, 2001, which claims the benefit of U.S.Provisional Application No. 60/251,285 filed Dec. 4, 2000, both of whichare incorporated herein by reference.

COPYRIGHT NOTICE

©2001 ThinkShare Corporation. A portion of the disclosure of this patentdocument contains material which is subject to copyright protection. Thecopyright owner has no objection to the facsimile reproduction by anyoneof the patent document or the patent disclosure, as it appears in thePatent and Trademark Office patent file or records, but otherwisereserves all copyright rights whatsoever. 37 CFR §1.71(d).

TECHNICAL FIELD

The present invention relates to software systems for distributed mobilecomputing and, more specifically, it includes a software platform—andapplication language—for deployment of portable, reusable, andinteroperable data viewing and modification applications in adistributed, intermittently networked environment.

BACKGROUND OF THE INVENTION

Increasing numbers of workers are mobile, meaning that they do theirjobs outside of the conventional office. Laptop and palm-sized computersprovide some communication and computing ability “on the road” and, withthe decreasing size of data storage devices of all types, mobile workerscan carry a lot of data with them. It is more difficult, however, toshare data with others or access a centralized database. Specifically,mobile users (or developers of wireless data systems) face severalchallenges, such as:

Disconnected operation. Workers often lose connectivity in certain areassuch as, subways, buildings, etc. but they should be able to continuedoing their job and, at a minimum, not have their data corrupted (eitherlocally or centrally) as a result of the disconnection.

Limited screen size and user input. It is difficult to display largeamounts of information, and enable a user to meaningfully “browse” theinformation on a tiny screen. User input is limited as well, especiallywith respect to PDAs and cellular phones.

Latency. Another challenge facing developers is how to designapplications that make best use of a range of bandwidths.

Manageability. Applications should be able to grow, adding features andfunctions, without rebuilding them from scratch and without losingbackward compatibility with other programs or services.

The value of separation of data and format has become widely known, oneexample being the use of stylesheets as described in U.S. Pat. No.5,860,073. Stylesheets alone, however, do not adequately address themobile user problems outlined above. For example, a stylesheet ortransformer can be written to translate data to HTML or WML for displayon a small screen. But if the result is long, downloading may takeawhile, and even if communication bandwidth is good, disconnection is arisk, and even after downloading, limited local processing power mayresult in long delay before the entire document can be randomly accessedby the user. Stylesheets enable some dynamic properties, but whenapplied in the context of a Web browser page viewing they do not providea complete solution for disconnected operation.

XML (eXtensible Markup Language) is a known document processing standard(a simplified form of SGML). It allows a developer to create a customvocabulary or “schema” defining a custom markup language. This can bedone using a document type definition (DTD) or with the XML SchemaDefinition (XSD), among other schema languages. The schema specifieswhat elements or tags and attributes can be used in a document and howthey relate to each other. Many industry-specific DTDs are evolving, forexample MathML, PGML, etc. XML parsers are publicly available forchecking “well-formedness” of a document (compliance with the XML syntaxspecifications) as well as “validity” meaning compliance with theapplicable schema.

The Information and Context Exchange (ICE) protocol is designed tomanage establishing “syndication” relationships and data transfer forcontent distribution. ICE is an application of XML. ICE enablesestablishing and managing syndicator—subscriber relationships fortransferring content that is generally originated by the syndicator andconsumed by the subscriber, such as news or weather reports. This systemessentially supports one-way distribution of content, i.e., publication,rather than interactive, mobile applications implementing andsynchronizing distributed databases. Still, it does suggest a datareplication scheme mediated by XML messages.

It has also been suggested to use text-based descriptive attributegrammar, like XML, to specify object-oriented applications. U.S. Pat.No. 6,083,276 to Davidson et al. describes such a method. It is limited,however, to essentially translating the application description (in anXML-like language) to a set of software objects such as Java® componentclasses. Each element declaration in the source (markup language) filemust be capable of being mapped to a corresponding application componentclass. Each element with children must result in a correspondingcontainer component with analogous child components. Every attributedeclaration must map to a corresponding property value in thecorresponding component, and so on. Thus the application must bedesigned from the outset to align very closely with a selectedobject-oriented language and framework. Desired extensibility, reuse andsimilar goals are sacrificed, although the concept of initiallydescribing an application using an XML-like syntax is interesting andhas some obvious benefits. The '276 patent to Davidson, however,primarily teaches an automated method for translating that descriptioninto a specific object-oriented program at which point the benefits ofthe descriptive attribute grammar are lost.

U.S. Pat. No. 6,012,098 teaches a system for isolating the retrieval ofdata from the rendering of that data. A data retrieval “servlet”executes a query, and converts the results to an XML data stream,delivered to a downstream rendering servlet. The rendering servletparses this XML data stream, using a stylesheet that may be writtenusing XSL, and creates an HTML data stream as output for communicationto a client computer.

XSLT, or Extensible Stylesheet Language—Transformation, is a useful toolfor working with XML documents. XSLT enables one to extract andtransform the source information in various ways, for example intoanother markup language like HTML as is commonly done. See FIG. 1.

Many software systems exist which implement or utilize the XML family ofstandards (XML, XSL, XPath, XML Schema Definitions, etc.). HTML and XMLbrowsers are common. Many enable offline operation by accessing cachedread-only data. HTML and XML editors are common as well, all of whichform part of the general background of the invention.

See also U.S. Pat. No. 6,167,409 to DeRose et al. “Computer System andMethod for Customizing Context Information Sent with Document FragmentsAcross a Computer Network.”

Glossary of Prior Art Terms and Acronyms

Application server—One of a class of commercially available softwareframeworks for integrating computation into a web server environment.

Load-balancing router—A router that takes into account the effectiveperformance of a set of computational resources when deciding where toroute a message.

N-tier architecture—A software architecture in which computing resourcescan be layered to any depth. In contrast to “3-tier architecture.”

Namespace name (Namespaces)—A URI uniquely identifying a namespace. SeeNamespaces in XML [Namespaces].

Public identifier (SGML)—Globally unique string to identify a resource.Could be accompanied by a system identifier, which was often afilesystem path on a private filesystem.

Public identifier (XML)—Unique identity string. See XML 1.0 [XML].

Self identity—Identity as self-assigned by an object, without the directassistance of an issuing authority. The UUID is a standard created tosupport the implementation of self identity. Self identity is needed insituations where it is not necessarily possible or appropriate torequest an identity from an authority.

Session—An object representing a cached state to optimize an end user'sinteraction with the system.

Synchronization point—The event during which a database incorporatesinformation from another database, thus instigating replication orupdating previously replicated information.

Unique identifier—Any identifier that defines a set of rules, that, iffollowed, guarantee uniqueness.

XML Extensible Markup Language—A simplified form of SGML, the StandardGeneralized Markup Language, in international documentation standard.XML is a document processing standard recommended by the World Wide WebConsortium (W3C).

XSL Extensible Stylesheet Language—A part of the broader XMLspecification. An XSL document or stylesheet transforms an XML inputdocument to an output document, essentially applying element formattingrules.

XSLT Extensible Stylesheet Language—Transformation—The transform portionof the broader XSL language specification.

XPATH—A syntax for describing a node set location in an XML documentusing expressions that consider the context in which they appear.

URI—Uniform Resource Identifier. See RFC2396 [URI].

UUID—Universally Unique Identifier. A 128-bit unique identifier that canbe allocated without reference to a central authority. From UniversalUnique Identifier [DCE].

SUMMARY OF THE INVENTION

The present invention includes computer-implemented methods for modularprogramming on distributed devices that brings together and extendsindustry standards in a unique way to create a platform for a class ofportable, reusable, and interoperable data viewing and modificationprograms that can operate in a distributed, occasionally communicatingenvironment, for example where client devices are loosely linked tohosts or servers via a wireless communications channel. The inventionbuilds on XML and related standards, including, but not limited to,Namespaces in XML, XPath, XSL , XSLT, XPointer, XLink, XHTML and XMLSchema Definitions [XSD].

A complete distributed programming model is achieved by enablingdeclarations of shared or private data storage, declarations of schematranslation, synchronization rules, editing actions, access rules,application packaging, label sets for default interfaces, andregistration for distribution and reuse. The invention exploits schemato enable seamless integration at both data and display levels. Anapplication defined for the invention can extend another onedynamically, even if neither developer was aware of the otherapplication.

Thus, one important aspect of the invention is a computer-implemented,incremental process for executing an application servo in a clientdevice. This process includes building a context tree in which each nodeexpresses (by reference) a complete current state of the executionprocess. For example, the context node content includes a pointer to anelement in the servo execution of which spawned the context node; apointer that identifies a current data context by pointing into a sourcetree; a reference to a parent context; and an ordered, potentiallysparse, list of pointers to zero or more child contexts.

Another feature of the incremental execution calls for the creation ofchild spacer nodes in the context tree representing unmaterialized childcontexts. These can be used for certain operations, and estimates,without waiting for evaluation of the entire source tree. In a presentlypreferred embodiment, the context tree is implemented using a relativeb-tree structure, and each spacer is reflected in an interior node entryin the relative b-tree structure to facilitate searching unmaterializedcontexts.

Another aspect of the invention is a servo definition language fordefining a distributed application that supports disconnected operation.The language typically includes the following types of rules:application data schema; transformation rules; transaction handlingrules; and interface object specifications. Importantly, the servodefinition language can also implement opportunity rules to realizeautomatic extension or integration of servos through opportunity-basedlinking of an interface component representing an instance of a schemafragment to a template.

The invention enables developers to rapidly create and deploy read-writedistributed data interfaces for systems that employ relational databasesor have XML interfaces. Even when wireless network service is available,efficient use of the network is important for the end-user and/or theservice provider (depending on the pricing structure of the servicecontract). The invention addresses this by allowing many actions to betaken without immediate use of the network.

Wireless service is unreliable and often unavailable (e.g., inbasements, rural areas, and commercial aircraft). While it is notpossible to access new information when service is not available, theinvention makes it possible to review recent actions and initiate newactions of common types. Further, the present invention enables thedevelopment of continuously evolving suites of applications bymaintaining integration with legacy “servos” as new servos are createdand deployed. Users need not be actively involved in the distributionprocess. Developers can focus their efforts on individual capabilitiesrather than frequent systemic overhauls. “Servos” as used herein,roughly analogous to applications, are more precisely defined later.

Additional aspects and advantages of this invention will be apparentfrom the following detailed description of preferred embodimentsthereof, which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified data flow diagram illustrating a common batchXSLT transformation process as known in prior art.

FIG. 2 is a simplified data flow diagram illustrating interactive servoexecution in accordance with the present invention.

FIG. 3 is a simplified block diagram of a distributed systemillustrating a deployment of the present invention in a wirelesscontext.

FIG. 4A is a code fragment from the asset management servo of AppendixB.

FIG. 4B is sample data in the schema of the asset management servo.

FIG. 5A is a multitree diagram illustrating execution of the servotemplate of FIG. 4A over the sample data of FIG. 4B.

FIG. 5B is an illustration of a screen display generated by the servotemplate of FIG. 4A.

FIG. 6 is an illustration of a context node for use in incrementalprocessing of a servo.

FIG. 7 is an illustration of an interior socket for use in forming arelative b-tree structure.

FIG. 8 is an illustration of an interior whorl for use in forming arelative b-tree structure.

FIG. 9 is a simplified illustration of a single b-tree structure for usein constructing a context tree.

Appendix A is a listing of a software description language (SDL) schemaconsistent with the present invention.

Appendix B is a sample asset management servo expressed in the SDL ofAppendix A.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following terms are used in the present description of theinvention. Some terms are described in this glossary only, while othersare explained in more detail below. It is provided here as a convenientreference for the reader.

Abstract interface object—An object that provides information to anend-user or other software component. An object that offers the abilityfor an end-user or other software component to provide information tothe software system, such as enabling a choice or providing informationin answer to a particular question.

Concrete interface object—An interface object representing a specificinterface component that interacts with a human or another softwarecomponent. For example, a graphical user interface widget such as a dropdown list.

Context, interpreter—An object which encodes, through its own data andthe objects it references, the internal state of the interpreter at aspecific point of evaluation. This is explained in detail below.Computing server—A server used to run servos and reconcile with backingstores and other datasources.

Database name—A string that can be used within one specific database asa short handle to another specific database.

Datasource—An information resource that implements the datasourceprotocol. Datasources may include resident databases managed by theinvention, specific computational resources (such as applicationswritten using other technologies), or gateways to other Internetresources.

Datasource declaration—The means of specifying the existence andaddressability of a datasource. Datasources are commonly registered withthe registrar.

Datasource protocol—A specific protocol for accessing informationresources. SOAP [SOAP] is an example of a datasource protocol.

Default servo—A servo associated by the registrar with a schema to beused in the event that a user encounters data in that schema and has notpreviously selected an application to use with that schema. Each schemahas at least one default application. Different servos may be associatedwith different element and attribute declarations.

Directory services—A location broker that provides a navigable index ofavailable services.

Front-end server—One or more functionally equivalent servers used toprocess incoming requests and route them to appropriate computationalresources using knowledge about the specific request (the content of thepacket). A front-end server(s) may be a component of a load-balancingrouter.

Incident reporting service—A service which tracks subscriptions toevents associated with particular resources, and informs subscriberswhen those events occur. Used most commonly to track dependenciesbetween source databases and databases that replicate parts of thesource databases.

Label—One or more strings or other objects such as sound or imagesassociated with an element, attribute, model group or other component ofschema that serve to provide identifying information for use in a userinterface.

Location broker—A component of the invention that can accept anidentifier for a resource and provide means to contact that resource.Resources are not necessarily local to the broker.

Opportunity—An association between a unit of schema and a view or otheraction that can provide a means to interact with, modify, or apply anoperation to, an instance of that same schema.

Public identifier—The public identifier used by the invention. Aninstance from a managed URL space. Compatible by subset with publicidentifier (SGML), public identifier (XML), URI, namespace name, uniqueidentifier.

Public identity—Identity as known to a central authority that issuesunique identifiers. (For the invention, the authority is the registrarand the identifier is the invention public identifier.)

Registrar—The system resource which manages the registration of schema,applications and datasources. The registrar enables reliableidentification and data mappings as further described below.

Schema translator—A software component that converts data of onespecific schema to data of another specific schema.

Servo—The unit of application packaging provided by the invention.

Servo definition language (SDL)—A language in which servos areexpressed.

Servo transition—The action in which use of one application naturallyleads to use of another by leveraging the common schema of theunderlying data.

Short identifier—Another term for database name.

Storage declaration—Declaration of a persistent storage tree. See below.

Synchronizer—A component of the invention which uses transactiondefinitions, synchronization point identifiers, time stamps, datasourcedeclarations and database instance-specific parameters to maintaincorrect database state across a set of related databases managed by theinvention. Also called transaction engine.

System identifier—An instance of a UUID used as a form of self identityfor resources such as databases.

Task allocator—A service that assigns interactive tasks to availablecomputational resources based on suitability to purpose (server load,access to resources, availability of cached database or session state).

Task scheduler—A component of the invention that assigns computationaltasks to available computational resources based on priority, aging,deadlines, load, etc. Typically the tasks handled in this manner are notin response to a current user request.

Transaction engine—Another term for the synchronizer.

View—A grouping of transformation rules and components that define allor part of the interface for a servo.

View declaration—Declaration of view—View declarations define how theapplication (servo) interacts with the user or another softwarecomponent.

Introduction to Servos

We refer to an application in accordance with this invention as a servo.More specifically, a servo is the unit of application packaging providedby the invention. A servo is created by “declaring” it in accordancewith an appropriate servo declaration language. In accordance with apresently preferred embodiment of the invention, an XML-based ServoDeclaration Language (SDL) is provided, portions of which are attachedas Appendix “A.” Those skilled in the art will recognize that other SDLsalong similar lines may be used within the scope of the presentinvention. Key aspects of the SDL will be described in detail below. Inpractice, a developer specifies (or references) an appropriate schema inthe SDL and then specifies (declares) a desired application, or servo,consistent with that schema. The schema definition language may use amarkup language-like syntax, such as XML. A sample servo, discussed indetail later, is shown in Appendix “B.” Another important aspect of thepresent invention is an incremental process for interpreting orexecuting an application servo in a client device (or a server). Thisprocess is described in detail later.

All other things being equal, the less information the author of asoftware application needs to provide, the less time the author willneed to spend to create and maintain the application. The presentinvention provides a concise way to declare distributed data managementapplications. The experience provided to the end-users is created byselectively combining servos, which may be created by different authors,and interpreting them on differing platforms. This process is assistedby keeping the quantity of specification provided by the developer to aminimum. Platform independence is achieved through a minimal platformindependent application definition, supplemented by platform specifictransformations where the defaults are not adequate to address the goalsof the application author.

As noted above, the present servo definition language (SDL) is anXML-based language in which servos are expressed. The XSL vocabulary isreferenced by the SDL schema. This enables developers who are familiarwith XSL to make use of their experience and allows some of theexperience gained developing servos to be used in other contexts.

Information about a particular session environment can be made available(subject to security restrictions) for reference by SDL through aspecially named input tree. Session environment information can include,but is not limited to, the physical location of the mobile user,identification of client hardware, quantification of availableresources, and status of communication channel.

Application data is available (subject to security restrictions) forreference in SDL as individually named input trees, using the names fromstorage declarations further described below. These stores can bereferenced as variables. Each characteristic of a servo preferably maybe identified as overridable or not. This enables or disablesuser-specific customization. A simplified diagram of data flow is shownin FIG. 2.

Consistent with a presently preferred embodiment, servos, data, andprotocol (including queries and query results) are all represented inXML. For any computational task, the inputs, the outputs, and theinstructions preferably are all expressed using XML. Since XML is simpleand compact to transport, this computational model makes it simple todeploy more hardware to handle loads. This includes the opportunity toutilize thousands of servers as well as the opportunity to movecomputation to “smart” (invention-enabled) clients when appropriate. Italso provides the means to transparently shift the underlying databasemechanisms to suit the different performance characteristics ofdifferent stores.

Further, the present invention can be said to implement “n-tierarchitecture”—a software architecture in which computing resources canbe layered to any depth. The architecture allows independent informationsources over a vast scale to be accessed through a single interface.Rich schema and interschema translation services enable information toflow across the layer boundaries without loss of context as furtherexplained below.

Several specific features of a servo declaration are described in detailbelow. First, we provide some context by illustrating at a simplifiedhigh level an illustrative deployment of the invention, followed by asimple servo example. The sample office asset database application willthen be used to illustrate incremental execution of servos and theexecution context tree construct.

Illustrative Deployment

In FIG. 3, a server environment 300 is shown as currently supporting twomobile users, Alice and Juan. A synchronizer component 310 communicateswith a corresponding mobile synchronizer 326 on Alice's mobile unit,such as a Palm Pilot or other PDA 322. Similarly, Juan's pocket PC 342includes a synchronizer component 346. Alice's PDA 322 includes localstorage or data cache 324 where schema, rules (servos) and data arestored. A replica 320 of Alice's storage is shown on the server 300. Inoperation on Alice's PDA device, an interpreter 328 executes selectedservos, interacting with data and with the PDA user interface. Data inthe local storage 324 is synchronized with the replica data 320 on theserver via the synchronizer components, as explained in detail later.

The local data cache provides the local storage for the synchronizationengine described below. It facilitates the sharing of data acrossapplications and provides support for disconnected operation. Forexample, an application managing purchase order information canintegrate seamlessly with an application managing customer information,creating a unified view.

Another aspect of the local data cache is the ability to provide aunified interface to shared as well as personal data sources.Applications provide views that can join individual data, shared data,and group data. The synchronization engines on the client and the servermanage all this data. The local data cache in a presently preferredembodiment includes indexing so as to enable efficient random access tolocal data.

Juan's pocket PC 324 similarly includes Juan's local storage 344,including data, schema and rules (servos). An interpreter 348 on Juan'spocket PC executes selected servos, interacting with locally stored dataand the Microsoft Windows user interface, supported by the WindowsCE^(R) or similar operating system. As before, Juan's storage has areplica 340 on the server 300 with which the mobile unit issynchronized. The pocket PC is an example of a “rich client” that wouldtypically include, in addition to the operating system software, asynchronization engine and a display engine.

The display engine's primary purpose is to translate interface objectspecifications onto the display of the wireless device, providing alayer of abstraction between the code and the device operating system.This component allows application developers to create applications thatcan run on multiple device-types in ways that optimize the userinterface for each device.

Actions normally handled using multiple windows on a desktop computer,become possible using a single view on a small screen, enablingdissimilar applications to work together without modification. Thisimportant flexibility enables system developers to be more responsivethan ever to the constantly changing needs of their clients.

The display engine features preferably include:

-   -   A unique class of concrete interface objects to assist users        making selections from large databases.    -   The suite of standard device interface objects—tables, pick        lists, buttons, etc.    -   A generic pop-up window supporting all UI and data types        available on the platform described herein.    -   The ability to bind a UI element to a piece of data without        needing to track changes backwards and forwards.

The transaction engine (or “synchronizer”) 346 addresses the challengesfacing users of wireless solutions when disconnection occurs.Traditionally, productivity grinds to a halt. Here, the transactionengine provides seamless operation—regardless of connected state—to theuser, enabling continuous productivity. Additionally, this featureenables the user to work asynchronously, in other words, every useraction does not require communication with the server. Thissignificantly enhances application performance.

The synchronization engine preferably includes the following features:

-   -   Transactional support-store, forward, and full rollback with        supporting UI components for handling related events.    -   Event synchronization control—a full suite of controls enabling        developers to determine when and how synchronization occurs,        including priority for individual transactions and classes of        data.    -   Background updating-allows the server to push information to the        client transparently.

Referring again to FIG. 3, Juan also has a WAP phone 350 that cancommunicate with the server 300 via a WAP Gateway 352. Anotherinterpreter instance 356 is deployed in the server 300 to execute servosselected by Juan via the WAP phone, and interact with him via the WAPuser interface 354. This illustrates a “thin client” deployment wherethe interpreter is deployed on the server rather than the client side.Wireless handheld data devices divide into two major categories: richclients and thin clients. Rich clients have local storage capabilitiesas well as processing power. Thin clients essentially only have theability to display data.

The present invention works for both environments. On rich clients, theclient-side code resides on the device itself. On thin clients, theclient code runs in the server environment as a virtual client andcommunicates with the device using available protocols. Offlinefunctionality is not available with thin devices, but they access thedata in the same manner. Nonetheless, the present architecture providesa consistent development environment for both types of clients byrunning the XML—based interpreter, XML storage interface, andsynchronization protocols in a virtual client module residing on theserver.

Server environment 300 also includes a registrar service 330 where eachuser's rules and schema are registered, as explained in greater detaillater. The registrar is a component storing the user applications or“servos” as well as managing the deployment and updating of newversions. It also is where data schema are registered, enabling theseamless migration from one application version to the next and enablinga seamless mechanism for dynamically rolling out new functionality toclient devices. This enables the developer to create a persistentrichness of applications over time, and able to manage the multipleversions within an organization.

On the backside, the server environment is coupled to a legacyrelational database 390, by virtue of an integration toolkit 388.Another synchronizer element 370 synchronizes data between the replicastorage 320, 340 and the external database 390. The synchronizer 370 canalso utilize other XML services 380. The server environment 300 furtherincludes a group storage element 392 including schema, servos and data.

Finally, the server includes a server side synchronizer 310. The serversynchronizer is the server's counterpart to the client synchronizer. Itsmain function is to speak not only to the clients, but also to thebackend databases. The server synchronizer includes the followingfeatures in a presently preferred embodiment:

-   -   Client synchronization—provides synchronization services with a        myriad of devices and handles data collision, store, forward,        and roll-back.    -   Backup and restore of local client data—allows users to use any        handheld device and still retain both personal settings and        local cache.    -   Interface with backend database—handles the transactions with        the backend databases ensure data integrity throughout the        system.    -   Transactional services—manages changes in data and ensures data        integrity between clients and servers in the event connectivity        is lost during the transmission of data.

In operation, a typical life cycle of a request from a mobile unit ishandled as follows. An incoming request first sees a load-balancingrouter that parcels requests out to front end servers. This is part ofthe “server environment” of FIG. 3. Once received by a front-end server,the URL is analyzed by a task allocator to determine an appropriatecomputational resource. The allocator uses a location broker todetermine what servers are involved (responses may be cached forperformance) and a performance monitor to assess the availability of theresources.

Once received by a computing server, the request is sent to aninterpreter instance for decoding. If there is already an activeinstance for the user's session, a reference to it is obtained from thesession object and the request is sent to that instance. If not, a newinstance is created and the request is sent to the new interpreterinstance. These objects are not shown in FIG. 3 as it is primarily adata flow diagram. At this point, further processing is dependent on thenature of the request.

We define a computing server as a server used to run servos andreconcile with backing stores and other datasources. An applicationserver is one of a class of commercially available software frameworksfor integrating computation into a web server environment. And a“session” as used herein refers to an object representing cached stateso as to optimize an end user's interaction with the system. Theseobjects are not shown in FIG. 3 as it is primarily a data flow diagram.

At this point, further processing is dependent on the nature of therequest. If the request involves accessing data that resides in anotherdatabase managed by the present system, a messaging service is used topost the request. The messaging service will use the location broker todetermine where to send the message that has been addressed using aplatform public identifier. Public identifiers in this context are URLsfor resources assigned through the authority of the registrar.

If the request involves accessing information from an external HTMLsource, the process is similar to above, except that the object thatreceives the message is not a database, but an adapter that knows how topost an appropriate request (or set of requests) to the web and convertthe result into XML. (Portably written adapters that do not rely oncached state can be run anywhere, so the messaging system can choose toresolve the request in the current address space.)

If the request involves accessing data local to the user's database thathas been replicated from elsewhere, a synchronization log is checked tosee if the database is within the grace period allowed by thedeclaration of the datasource. (These services are further describedlater.) If so, the replicated data is used without furtherinvestigation. If the database is out of date, a request is sent to thedatasource directly using the messaging service. The datasource respondswith the synchronization packets required to update the local database.The update is performed and then the original request is processed.

A Simple Servo Example: The Office Asset Database Application

FIG. 4A shows a simple example of a servo template which would typicallyappear as part of a servo declaration. FIG. 4B is a database fragmentassociated with the servo template of FIG. 4A. Each line of code in thedrawing is numbered at the left side (400-419 in FIG. 4A, 420-434 inFIG. 4B). These numbers are provided for reference in this description,they are not part of a sample code. Referring now to FIG. 4A, thexsl:template declaration defines the corresponding fragment of dataschema, in other words the associated data type, by reference to the“wh:obj” element. Line 402 borrows the standard html tag for defining adivision of the output resulting from this execution. In line 404, thehtml:span element employs the xsl “value-of” instruction, generally usedto generate output, with the attribute select=‘@barId’. This is theXPATH formulation to obtain value of the barId element of the databaseobject. Referring to FIG. 4B, the first object in line 422 has the barIdvalue equal to ‘271’. Consequently, execution of this servo will outputthe number 271 as illustrated in FIG. 5B.

Referring again to FIG. 4A, line 406 asserts an edit instruction fromthe “ts” schema, with a matching criterion (“select”) of the descriptionelement (“desc”) of the same database. (“ts” alludes to ThinkShare,assignee of the present application.) The edit instruction is defined inthe schema of Appendix A. It provides for display of an editable fieldin the user interface. In this case, it operates on the descriptionelement of the database, which appears in FIG. 4B at line 424 having thestring value “black metal cabinet.” Accordingly, the string “black metalcabinet” is displayed on the user interface as shown in FIG. 5B.

The <ts:expandable> and <ts:hideable> elements are described in detailin Appendix “A”. The remaining lines of code in FIG. 4A are merelyclosing tags.

Returning to FIG. 4B, a first object is described in lines 422-426 andsecond object is described in lines 428-432. The second object is shownat line 428 as having a band attribute value of ‘259’ and last attributevalue of ‘271’, the latter being a pointer to the previous object. Thesecond element 259 has a description “top shelf” which is then displayedas shown in FIG. 5B, by virtue of the apply-templates instruction shownat line 412 of FIG. 4A. The xsl:apply-templates element selects a set ofnodes in the input tree, and processes each of them individually byfinding a matching template rule for that node. The set of nodes isdetermined the select attribute, as noted, which is an XPATH expressionthat returns a node set. The key used in this expression is a persistentone declared as part of the servo.

FIG. 5A is a portion of an interpretation multitree illustratingoperation of the servo template of FIG. 5A on the database fragment ofFIG. 4B. This is an abstraction of the context records created duringthe incremental process of executing an application servo. FIG. 5Aincludes essentially two related tree structures—the servo executiontree and the output or geometry tree. The execution tree comprises thecircles, for example, the root node circle 500, while the geometry treecomprises the squares in FIG. 5A. With respect to the execution tree,each circle corresponds to a “context” which in turn reflects a specificstate of the execution process. The tree begins at the root node 500which identifies the template corresponding to FIG. 4A.

FIG. 6 is a simplified illustration of a single context node(corresponding to one of the small circles in FIG. 5A). Each contextnode includes an interpretation tree parent pointer, an interpretationtree root, a geometry tree parent pointer, geometry tree root pointer,and additional context information as described below. Later, wedescribe the use of “spacers” as a proxy for a plurality ofunmaterialized context nodes, and a relative b-tree structure forencoding the interpreter context tree. First, we further explainimportant elements of the servo language.

Schema Declarations

The principal types of declarations are:

-   -   Schema    -   Labels    -   Abstract interface objects    -   Storage declarations    -   Concrete interface objects    -   Abstract interface objects

The currently preferred embodiment of the invention uses XML SchemaDefinitions as the core vocabulary for defining schemas. In principle,other means of specifying schema can be used. In addition, the inventionprovides enhancements, discussed later, which enhance the usefulness ofschema in the context of the invention.

One such schema enhancement is called a “label.” Here, a label is one ormore strings or other objects such as sound or images associated with anelement, attribute, model group or other component of schema thatprovides identifying information for use in a user interface.

Objects declarable as labels include, but are not limited to:

-   -   strings representing natural language    -   bitmap or vector graphics    -   voice recordings    -   other sounds, specified by any means

Textual labels of various lengths and languages can be provided by aservo author using the example syntax provided in Appendix A. Shorterstrings can be used as abbreviated labels, longer strings or elementsubtrees as descriptions or documentation providing user assistance.Labels are accessible to servo authors through an additional XPath axisor an element vocabulary within the schema axis. Labels are particularlyuseful for creating servos that must deal with a large number ofdifferent languages and/or schemata.

Additionally, certain abstract interface objects provided by theinvention make use of labels to generate user interface objects based onthe language context without need for explicit reference to labels viaXPath. For example, the <> element in the sample syntax provided inAppendix A specifies a labeled editable field, without need toexplicitly reference the label. Other abstract interface objects canmake implicit use of labels, including, but not limited to:

-   -   tables with headings    -   tool bars containing icons representing actions    -   voice prompts

Storage Declarations

A storage declaration is the means by which a servo author reservesnamed persistent storage for use by the application and any other servosthat may be authorized to access the data. Storage declarations define alocally scoped name for a persistent storage tree, and specify theschema to which the storage tree must comply. Note this refers to a dataschema, not a servo declaration schema. An example of a storagedeclaration is shown in Appendix “B.”

The lifetime of external data varies. Old stock quotes (complete withtime stamps) have unlimited shelf life, but little utility to theindividual who wants only the latest quote available. Weather forecastsmay be updated several times a day, weather observations several timesan hour. Personalized recommendations from a commerce site may not needto be updated more than a couple times a week. For these reasons, theauthor can declare the lifetime of data obtained from a given source.The lifetime may vary for different elements of the schema.

Collaborative datasources, such as a shared shopping list, may require asynchronization check each time they are accessed. The author declaringthe storage can also declare the form of acceptable queries and thecorresponding query results. An illustrative example of a storagedeclaration schema is shown within the schema of Appendix “A.”

Specifying Concrete Interface Objects

A concrete interface object is an interface object representing aspecific object which interacts with a human or another softwarecomponent. Some representative concrete interface objects include, butare not limited to:

-   -   1. an editable text field    -   2. a voice prompt answerable with a voice response    -   3. an XML message sent to another subsystem, answerable by an        XML response message    -   4. a one-of-n choice presented as radio buttons in a graphical        user interface    -   5. a one-of-n choice represented as a pull-down or pop-up menu        in a graphical user interface    -   6. a one-of-n choice presented as voice prompt offering choices        that can be made by typing keys on a telephone or other device    -   7. a paragraph element (“p”) in XHTML    -   8. an XSL formatting object

A graphical user interface specified by the invention can use elementsfrom a number of vocabularies, including XHTML, XSL. In particular, thecommon user interface elements, including, but not limited to forms,buttons, menus, editable fields and tables may be specified using anynumber of vocabularies. In addition to common graphical user interfaceobjects, the invention provides for use of concrete interface elementsthat provide structural views of information. For example, the inventionprovides concrete interface objects that expand to display additionalconcrete interface objects in response to user commands. These devicesare particularly useful when combined with opportunities, describedbelow. The combination of these interface devices with the method of“view declaration” provides particular advantage to users of handhelddevices with small displays.

Specifying Abstract Interface Objects

Recall that an abstract interface object is an object that providesinformation to an end-user or other software component. An abstractinterface object can be used to enable an end-user or other softwarecomponent to provide information to the software system, such asenabling a choice or providing information in answer to a particularquestion. The invention enables developers to specify a user interfaceor software interface using abstract interface objects that areindependent of the specific concrete interface object that may be usedwhen the specification is interpreted, for example when a servo isexecuted, in the context of a particular device or system.

Example abstract interface objects include, but are not limited to:

-   -   choice of 1 of n options    -   choice of m of n options    -   ability to specify a value for a specific instance of an object        defined by schema, providing the current value as an option    -   progressive disclosure of means to specify information    -   a group consisting of other abstract interface objects

Specification of an interface using abstract interface objects ispreferred over concrete interface objects because it enhances theportability of the interface thus defined.

Specifying Views

Recall from the glossary that a view is essentially a selected groupingof transformation rules and components that define all or part of theinterface for a servo. It is implemented by a view declaration. Viewdeclarations define how the application interacts with the user oranother software component. See Appendix “A”.

The declaration of views uses the XSLT vocabulary combined withextensions. The XSLT input trees correspond to declared data storageareas, and the output tree is a specification of the interactive userinterface. XSLT provides a mostly declarative vocabulary fortransformation. The invention allows the input tree to be modified as aconsequence of transformation, as described in Specifying datamodification. Use of the XSLT vocabulary does not imply a batch processfor transformation. The invention uses the vocabulary to specify aninterface that changes dynamically as the preconditions oftransformation change. This process is described in the Interpretingservos section.

Example extensions include, but are not limited to the followingelements, as illustrated in the schemas which accompany this document asAppendix “A”:

-   -   the <view> element    -   use of variables, available to XPath, which identify input trees        corresponding to storage declarations    -   an additional XPath axis providing access to schema information        corresponding to the addressed data    -   an additional XPath axis providing access to origin and change        history of the addressed data    -   an additional XPath axis providing access to opportunities (as        defined below) associated with the addressed data

Operation of such extension is described in the interpreting servossection.

Specifying Opportunities

Recall that an opportunity is an association between a unit of schemaand a view that can provide a means to interact with, modify, or applyan operation to, an instance of that same schema. Opportunities thusallow servo authors to declare schema fragments for which the servo canprovide alternative views or special actions.

For example, any number of applications can register the fact that theyprovide actions that can be performed on the address element of aparticular schema. These actions might include indicating which side ofthe street the address is on, providing latitude/longitude coordinatesfor the address, providing driving directions from the current location,providing distance from current location, providing a map of the area,etc. These actions are available to users of applications that displaydata encoded in the target schema element. This is done both by allowingthese templates or views to be called directly and by run-time discoveryof options and display of those options to end-users of the servos.

Opportunities associated with objects are available to XPath expressionsas functions and/or variables. This enables servo authors to discoveropportunities at run time.

The invention can also be configured so that the declaration of anopportunity results in the opportunity being listed with certainabstract interface objects so that choices are presented to the userwhen the user is interacting with the object, regardless of what servois being employed.

Operation of servos can be further illustrated with the followingelectronic commerce example. The kind of information that consumers maykeep in databases managed by the invention can be extremely useful inpredicting future purchases. For example, a list of “movies I want tosee” can be interpreted as a list of “movies I want to buy.” Any numberof commerce servos can be introduced into a pre-existing set of servos,and be readily accessed from views of those servos by making use ofopportunities declared by those servos.

Take for example a servo “A” that manages a personal library, andreading list. The schema for the personal library contains various viewsof book metadata which utilize a schema that includes a <book> elementthat has an ISBN attribute. A servo can be added which declares one ormore opportunities associated with the <book> element, and offers ameans to submit and track orders to one or more book suppliers.Additional servos can be added to track all outstanding orders and toprovide status information from various carriers.

A servo can be used with a datasource that maintains user preferencesand makes recommendations, such as is found at moviecritic.com oramazon.com. Such a servo can maintain a client side list of movieratings that are reconciled with ratings found by crawling the siteusing the user's authentication credentials. When used in combinationwith servos oriented at purchasing or viewing products, the end-user isable to use multiple rating engines with the same set of ratings, andany set of purchasing servos. Thus, the invention can be used to helpcreate electronic markets.

Other Types of Servo Declarations

Consistent with the presently preferred embodiment, operations that mustbe performed as a transaction are enclosed in transaction tags in thecontext in which they are defined. Operations not so grouped areprocessed individually. Transactions can be nested. Editing actions arespecified using an XML vocabulary that covers operations that can beperformed on an XML tree, such as the editing actions supported by theW3C Document Object Model.

Specify Access Control

The sample schema given in Appendix “A” provides an example of an accesscontrol model. The invention can be used with any number of accesscontrol models. Access control can be based on your role in a community,the specific data-types you are modifying, their context in the databaseand the control attributes on those objects or their closest containerhaving such control attributes.

Structure of Databases Managed by the Invention

The preferred embodiment of the invention uses a native XML databasewith persistent, incrementally updated indices. Alternative databaserepresentations can include a simple XML file parsed and loaded atapplication startup, as well as a relational database.

The logical structure of the database is described here as if it wererepresented in XML, although other persistent representations arepreferred, as explained above. Within each database are regions, whichcan contain, among other data:

-   -   identification information for the database    -   declarations identifying other databases    -   servos installed in the database    -   named storage regions associated with servos    -   a transaction log with all changes encoded in XML, including the        operations required to back out each transaction.

Example schema for a database is given in Appendix “A.” This descriptionapplies to both local storage and server replica storage (see FIG. 3).

Process of Interpreting Servos

Servos are distributed on request or by pushing the servo definitioninto the offline store. The servos preferably are stored in parsed form.Alternatively, servos can be stored as unparsed XML. Alternatively,servos can be stored and distributed in a compiled form, such as wouldbe used on a virtual machine, or actual machine code. Storing the servoas the data is stored enables the same tools to be used for storing,indexing, accessing, transporting, synchronizing and transforming theservos. However, compiled representations can be used to achieve betterperformance and/or smaller size. Byte code or machine coderepresentations can also be translated on device from unparsed XML orparsed XML forms and cached locally to improve performance. Theinvention is described here in terms of the parsed representationoption. The incremental interpretation process described below appliesto XSLT transforms as well as servo definitions. The interpretationprocess requires first understanding the concept of “context” in greaterdetail.

Details of Context Content

Basically, an interpreter context is an object which encodes, throughits own data and the objects it references, the internal state of theinterpreter at a specific point of evaluation.

The component that performs the incremental transformation is called thetransformer. The internal state of the transformer is organized intorecords, here called contexts. Each context specifies the evaluationstate of the transformer at a specific point in the transformationprocess. Each context node can include at least the following content:

-   -   1. A pointer to an element within the servo template, XSLT        stylesheet, or a node within an abstract syntax tree of an XPath        expression contained in the transform. This serves as a program        counter. This representation can be XSLT source, a parsed XSLT        transform or a further compiled representation such as        instructions in an XSLT virtual machine or hardware machine        code.    -   2. A pointer that identifies the data context. It is a pointer        into a source tree, or a result tree fragment.    -   3. An ordered list of zero or more contexts that provide a        symbol space for the context. Intermediate contexts in the tree        that do not introduce symbols may be skipped.    -   4. A reference to a parent context.    -   5. An ordered, potentially sparse, list of pointers to zero or        more child contexts. In the preferred embodiment, these child        contexts are contained in a data structure that encodes the        relative order of materialized contexts, including the ability        to encode unmaterialized regions of unknown size. An example of        such a data structure is a b-tree in which materialized contexts        and objects representing regions of unmaterialized contexts are        maintained in order. This b-tree structure is further described        below.    -   6. Definitions for symbols introduced by the context. Such        symbols include variable declarations, parameter declarations,        template declarations, view declarations, and data declarations.        Contexts preferably encode the differences from the symbol        context inherited from their parent(s). This includes        declarations of variables and templates. Thus each context,        through use of its parents, represents a complete XSLT processor        state.    -   7. In the preferred embodiment of the invention, the transformer        contexts also encode the current synchronization state.    -   8. Further, contexts can reference cache result trees, along        with signatures of the types of changes that would invalidate        the cached results. These result trees can represent components        of a user interface.

B-Tree Structure and Spacer Operations

Unmaterialized regions can be of known length or unknown length.Unmaterialized regions of known length encode the length of the regionas a count of missing contexts. This is called a spacer in the contextof the execution tree. Unmaterialized regions of unknown length aredistinctly marked and include an estimate of the number of missingcontexts. When there is no basis for a better estimate, a predefinedconstant is used.

As mentioned earlier, a spacer can be used as a proxy for a plurality ofcontexts. There is an obvious savings from not creating context nodesthat may never be needed. We leverage the b-tree structure to implementspacers. In a presently preferred configuration, we make use of theinterior b-tree nodes, which are called interior whorls in FIG. 8, tostand in for the unmaterialized context or contexts. That's done withinthe interior socket structure as described with reference to FIG. 7, aspart of an interior whorl, setting selected bits and, instead of havinga pointer down to a context, use that same storage to indicate that thecontext is unmaterialized (which is to say it doesn't actually exist)and to indicate the number of unmaterialized objects that correspond tothat object, as well as estimates for metrics such as the sum of Y spanelement (b) in FIG. 7.

Also, at each level of the b-tree of FIG. 9, there are a set of flagswhich are used for a number of different purposes. Specifically, thesecan include flags that are searched for as part of the search criteriain the execution algorithm. Among them is a flag that indicates whetherthere is unmaterialized context (spacer) present. The search criteria ofthe algorithm can quickly investigate whether there is a context thatneeds processing, or it can search at the same time for unmaterializedcontexts. (An unmaterialized context can be thought of as a context thatneeds a lot of processing. It doesn't even exist yet.)

When first processing an instruction that contains child instructions,an unmaterialized region (represented by a spacer) is created tocorrespond to all of the child instructions. Searching forunmaterialized regions is the primary mechanism that draws the processforward and causes new contexts to be created. Here the term “region”refers to a fragment of the geometry tree, corresponding to a region ofuser interface, for example a portion of a screen display.

Once an unmaterialized region is found that satisfies a given set ofcriteria, for example whether it is on-screen, the interpreter can“carve off” a piece, at one of the ends or in the middle, creating a newspacer or adjusting the existing spacer as required to accommodate a newcontext node.

In a presently preferred embodiment, the context tree is implementedusing a relative b-tree configuration. FIG. 7 illustrates a singleinterior relative b-tree node entry. Each entry in the interior nodes ofthe b-tree contains a value that is the sum of the lengths (includingmaterialized contexts, unmaterialized regions of known length andunmaterialized regions of estimated length), and a flag indicatingwhether estimated lengths were included in the sum. These values arepaired with a pointer to the corresponding child node in the b-tree.

Referring to FIG. 7, the interior socket 700 includes (a) the sum ofnumber of context node children, transitive over interior whorls, butnot beyond the first level of context nodes. Second, element (b)contains the sum of y span, transitive over all levels below. The nextelement (c) comprises flags, including the union of all flags below. Andfinally, element (d) is a pointer to the child (context node or interiorwhorl) or cached information about unmaterialized object.

FIG. 8 illustrates an interior whorl of the b-tree 800. In this interiornode, each column 802, 804, 806 defines an interior socket as describedwith reference to FIG. 7. FIG. 9 is an illustration of a portion of theinterpretation tree. It includes a parent node 900 and plurality ofchild nodes, for example, 902 and 904. The relative b-tree implementsinterior sockets 910, 912 and 914. In this system, each Wt node can beparented separately by an interpretation parent and a geometric parent.In turn, each node can separately parent an interpretation tree and ageometry tree.

Additional fields can also be included in the b-tree node entries totrack other linear values such as the y-axis of an image space that canbe mapped to a graphical display. For example, this can correspond tothe height of a PDA screen display. This data structure enables contextsto be materialized incrementally. Relative addressing can be performedin logarithmic time within spans of the tree that do not containunmaterialized regions of unknown size by walking the tree structure inthe usual manner of traversing a relative b-tree. Similarly, absoluteaddressing can be performed in logarithmic time up to the occurrence ofthe first unmaterialized region of unknown size. Estimates derived fromthis data structure can be used to satisfy scroll car sizingrequirements of graphical user interfaces. In short, use of this datastructure supports an incremental execution process that enablesimmediate output to the mobile (or local) user regardless of the actualdatabase size.

Contexts are evaluated by performing the operation implied by theinstruction addressed by the program counter and reflecting the resultin a context. The details of the evaluation depend on the specificinstruction. Evaluation actions include, but are not limited to thefollowing:

-   -   Variable and parameter declarations introduce symbols    -   Literal elements copy themselves to the output tree    -   Concrete interface objects are passed on to the user interface        subsystem    -   Abstract interface objects are mapped to concrete interface        objects using platform-specific rules    -   Control constructs such as <xsl:if> determine which subtrees are        processed further.    -   Creating a spacer to correspond to all child instructions.

Several techniques can be used to encode the types of change that couldrequire that a context be reprocessed. Some optimizing space, someoptimizing the amount of unnecessary computation that is performed dueto false positives.

-   -   A context may express dependency on instances of a specific        schema component. For example, an interpreter context which        references an XSLT statement including an XPath query that        depends on the value of “y” attributes on “x” elements could        register interest in any changes to values of “y” attributes on        “x” elements (including the addition or deletion of “x” elements        having “y” attributes).    -   Dependency on source trees can be generalized to an XPath        expression identifying nodes whose change would require        reprocessing. Such an expression can be derived from XPath        expressions in the stylesheet element addressed by the program        counter.    -   An interpreter context whose processing result depends only on        its ancestors and the value of a single element or attribute        instance can register an interest in that element or attribute        instance.    -   All contexts express dependency on XSLT stylesheet content        through their program counter.

Contexts are marked “unverified” when state they depend on has changed.When a context is marked unverified its ancestor contexts are flagged ashaving unverified contexts below. This can be used to rapidly search thecontext tree(s) from the root(s) for contexts that need to bereprocessed.

When an unverified context is selected for processing several techniquescan be used:

-   -   The context can be evaluated, as if for the first time, in its        current context. The result of the evaluation is then compared        to the previous value.    -   The change log can be examined to determine the precise nature        of the differences. In some cases (false positives) these        differences can be determined to not affect the result.    -   The change log can be examined to determine a corresponding        change to the output tree. For example, consider a query        returning a somewhat different set of nodes. Nodes in only the        new set must have corresponding contexts created. Nodes in only        the old set must have their corresponding contexts deleted.

In each case, if the context has an identical effect to its previousevaluation, no changes need to be made to the output tree, and no childcontexts need to be marked as unverified as a result of the evaluation.If the result of reprocessing is different than the previous processing,any child contexts that could be affected by the difference are markedunverified.

The choice of what context to process is driven by specific objectivesof the software component requesting the transformation. Theseobjectives can include:

-   -   The need to fill the visible portions of a formatting object        with content.    -   The need to satisfy a request for data that is the object of a        schema translation.    -   Processing to prepare the system to respond quickly to likely        user action.

In order to effectively manage limited resources the processor canrelease contexts and associated fragments of the result tree. Releaseobjectives can be set to work within a specific memory quota. Theinvention chooses contexts for release by scoring on the followingcriteria:

-   -   Contexts nearer the interior of the tree are preserved over        contexts near the leaves of the context trees.    -   Contexts which required substantial computation on previous        evaluation are preserved over contexts which required little        computation.    -   Contexts which are responsible for less memory are favored over        contexts which use more memory.    -   Contexts which carry decorations of the source or result trees        are maintained as long as possible.

Other Features and Advantages of the Invention

The present system preferably validates data modification by rejectingediting transactions that violate data schema constraints. The entireeffect of a transaction should be considered when validating schemaconstraints, although individual actions that make up a transaction neednot yield valid intermediate results. In particular, the net result of atransaction must leave attribute values that match their declared type,and element structure that matches declared content models. Theexistence or absence of attributes should also be consistent with thecorresponding element declarations.

The present system also rejects transactions that would violate accesscontrol constraints (described below) and transactions that wouldviolate data mastering. And the present system ultimately rejectstransactions that are rejected by the datasource that masters the data(described below). For maximum security, read and modification controlare enforced by the mastering datasource. Modification control isenforced on the client and offline replicas as well as the server. Bydefault, the database in which an object was created is the master forpurposes of replication. This means that any modification that can beachieved through that creating database (subject to access controlmechanisms) will be propagated to replicating databases assynchronization points with those databases occur.

The invention can be used in combination with encryption technology toprovide private and authenticated access to remote datasources. Forsecure applications, the server preferably authenticates user identitieswhen processing requests from client devices. User authentication iscentral to higher level security mechanisms such as access control andmanagement of paid subscriptions.

Embodiments of the invention also can use digital signatures to ensurethat servos delivered to a client device come from a trusted source.This model is similar to Microsoft's ActiveX control distribution model.A preferred implementation also provides robust access controlmechanisms for users, content, and applications. Users can be givenrights only to certain applications or certain data delivered to thoseapplications. When a user registers for an application, his or heraccess rights are checked against the application's rights list that hasbeen set up by the application's administrator. If the rights match, theuser is allowed to install the application. Content can be given accesscontrol lists as well, enabling a single application to serve differentlevels of content to users with different access rights. For example,within a corporate environment, only the authorized accounting staffwould have rights to see quarterly revenue figures before they wereannounced, but everyone could see historical figures that had beenpreviously publicly announced.

Application Rights Arbitration: The client can be configured to providea mechanism similar to the Java sandbox concept wherein the clientenforces a set of rules governing what types of actions an applicationcan take. Rules govern things such as writing data to the device'spersistent storage, interacting with built-in applications, andrequesting data from foreign servers. The user controls the settings forthese rules. For instance, the user may allow any action to be taken byan authenticated application whereas tighter security might be appliedto untrusted applications.

Content Authentication and Version Checking: In many business situationsit is crucial to establish that information has not been tampered withand that all information components are of the right version. Consider,for example, the management of aircraft maintenance publications whereit is required that all current service bulletins be displayed and thatno un-approved documentation is displayed. The present system enablesthis to be accomplished through the synchronization processes byauthenticating all messages through encryption, including messages whichdefine configurations that are current as of a particular time.

Schema authentication and Version Checking: The invention can bedeployed in an environment where servos come from a variety of sources.It is valuable in such cases to establish that new schema contributionscome from authorized sources and that incompatible versions of schemacomponents are not used together. Details of implementation will beapparent to those skilled in the art in view of this specification.

The server environment of the present invention also enables content andapplication providers to support subscription or pay-per-usedistribution. Content providers might require a paid subscription toaccess their content. Thus, users' subscription status can be taken intoaccount when checking access control. Content providers might alsoprovide pay-per-use content. Embodiments of the invention can providethe infrastructure for collecting payment and ensuring that pay-per-usecontent is only delivered to paying consumers. Again, the particulars ofimplementation will be apparent to those skilled in the art in view ofthis specification and in any event will vary with the particularapplication.

User Management of Asynchronous Transactions: End-users can engage inasynchronous actions and can inspect the status of the task queue. Thepreferred embodiment includes user interface components that indicatewhen there are transactions in the following states:

-   -   Transactions that have not yet been communicated to the server        or datasource.    -   Transactions that have been communicated to the server but for        which no response has been received.    -   Transactions that have been confirmed by the server as having        been successfully completed.    -   Transactions that have been rejected by the server but have not        yet been viewed or acknowledged by the user.    -   Rejected transactions that have been viewed by the user but have        not been acknowledged.

These interface components enable the user to quickly determine whattasks have been carried out or need to be attended to. In addition, thesystem can provide user interface components that enable users toinitiate operations on transactions that are accessible through theinterface described above. These actions include, but not limited to:

-   -   Viewing transactions in the context in which they were created    -   Canceling transactions    -   Modifying transactions that have not yet been communicated to        the server and    -   Coping and modifying a rejected transaction to be resubmitted

Resource-Level Identity and Element-Level Identity

Embodiments of the present invention employ two kinds of identifiers:public identifiers and system identifiers. Public identifiers preferablyare URLs for resources assigned through the authority of the registrar(330 in FIG. 3). System identifiers are UUIDs assigned without theassistance of any central authority when resources such as databases arecreated.

The invention implements a form of self identity as well as publicidentity because not all resources can be known to a public authority atall times. Take for example an environment in which the client has beendistributed to a group of individuals without current network access.These individuals must be able to begin using the application rightaway. Using the application, however, can involve sharing informationwith others. The identity of this information needs to be tracked as ittravels, so a unique identifier must be assigned. Since a centralauthority cannot be contacted to assign a public identity, the systemmust fall back on using self identity to track the information.

For reconciliation accuracy, performance and automation, units ofinformation managed by the invention can be uniquely identified at afine degree of granularity. Indeed, the reader will no doubt appreciateby now that the granularity is limited only as defined by the applicabledata schema. Unique identifiers must be scoped in such a way that noglobal mechanism is necessarily required to dispense the identifiers.(Note however that a central authority could be used when available.)

Local and Global Identification with Short Forms

Recall that a “database name” is a string that can be used within onespecific database as a short handle to another specific database. Ashort identifier is another term for a database name. The databases thatthe invention manages are identified using UUIDs.

Fully qualified global identification of an object is achieved bycombining the identity of the creating database with a UID scoped tothat particular database. When within their originating database,objects can be identified using a locally unique identifier. Within aspecific database, other databases can be referenced using shortidentifiers which are scoped within the referencing database. Shortidentifiers can always be normalized to long forms to provide locationindependent identifiers.

In the sample embodiment, individual elements are identified with the“ts:u” attribute, which is an attribute defined on a “base” archetypethat facilitates management of data. All element types that requiregeneralized unique identification are below “base” in the impliedinheritance graph. The value of the “ts:u” attribute consists of adatabase name followed by a local id, with a “#” separator. For example,in a database where “b” is a declared database name, an element withidentify “2” scoped to within database “b” will have a “ts:u” attributevalue of “b#2.” Database names are declared with the <dbDecl> element inthe sample schema found in Appendix A.

Elements which are not identified with the “ts:u” attribute areassociated with the nearest ancestor that has a “ts:u” attribute. Suchunidentified elements can be accessed with XML linking mechanisms. Thesepointers would be relative to the nearest ancestor with a “ts:u”attribute. UUIDs are encoded as a string of 32 hexadecimal digits with adash delimiter (“-”) after the 8th, 12th, 16th and 20th digits. For afull specification see the Distributed Computing Environment [DCE]specification. For example: “2facl234-31f8-11b4-a222-08002b34c003” is avalid UUID.

In the sample embodiment, the UUID for a database is indicated by the“systemId” attribute on the first “ts:dbDecl” element. The UUIDs forother databases having elements replicated in this database are given as“ts:uu” attributes on the “ts:db” element under the “ts:imports”section. The local alias for each database is given as the“ts:localAlias” attribute of its “ts:db” tag. (See the schema inAppendix A.)

While it is possible to fully normalize all data represented in XML sothat it is isomorphic to a normalized relational databaserepresentation, and while this is an appropriate encoding for manyapplications, the invention does not require that this be done with alldata. This allows document-oriented characteristics to be provided bythe invention. These characteristics include presentation order forelements and choice of primary location for multiply referenced objects.

Element Surrogates and Structural Referencing

It is also suggested that instances of the invention include an aliasingmechanism that allows the structure of cross-linked XML to be fairlythoroughly checked with existing XML tools and allows the structure ofthe database to be easily interpretable by humans. In the sampleembodiment, the “base” archetype includes an “ts:aliasOf” attribute oftype IDREF which can be used to reference an element of the same typewhose attributes and content serve as the attributes and content for thereferencing element. Most processing utilities operate above the levelwhere knowledge of these aliases is necessary. Lower level utilitiesexpand these aliases as an automatic service.

This same reference mechanism can be the basis for element instanceinheritance. This provides a means to extend data replicated from otherswhile minimizing resolution conflicts. Low-level utilities interpretinheritance automatically. Transformers to expand aliases can be used tosimplify operations for downstream transformers. When aliases have beenexpanded it is possible to discover the original source of theinformation by examining special system maintained attributes oralternative XPath axes.

Since aliases can in turn reference other aliases, information can beadded at each level. Any number of subtrees can contribute to the finalvalue of an alias chain. Since multiple transformations can be composedtogether it would not be uncommon for multiple instances of the samerecord to turn up at some phase of the transformation process when onlya single instance is required. The “ts:u” attributes described above arethe primary mechanism for identifying copies and eliminating duplicateswhen that is appropriate. By default, when an alias is expanded, theresulting element acquires the “ts:u” attribute of the referencedelement. This is the appropriate action when the alias exists tofacilitate a tree-oriented view of non-normalized data.

In the sample embodiment, the “base” archetype includes a “refPath”attribute of type IDREFS. When an alias is expanded, the value of the“ts:u” attribute of the referencing element is appended to the list. Inthe sample embodiment the “base” archetype further includes an “inhPath”attribute of type IDREFS. When an ancestor is processed that contributesattributes (other than “refPath”) or content to the expanded value, thevalue of the “ts:u” attribute of the ancestor is appended to the list.The values of certain attributes can apply to an arbitrary amount ofinformation which may be grouped together in a subtree. Attributeinheritance may or may not follow aliases. Whether or not it follows isa choice of extended schema and/or application design. When possible,personalization should occur through refinement (e.g., via inheritance)rather than through making individualized changes to replicated data.

Managing Change

Recall that changes to data are the subject of messages between clientand server, as illustrated in FIG. 3. Editing actions are specified interms of operations on an abstract XML model. For example, operations asdescribed in DOM. The invention creates logs of changes as they occur.Edits are placed in the log prior to being performed. This is called anedit log or transaction log.

A sample syntax for communicating change information is provided as partof Appendix A. In particular, <syncRequest> messages are requests forupdates to a particular piece (or pieces) of replicated data.Information in a syncRequest may include:

-   -   The “ts:u” attribute values (discussed above) of the root nodes        of the subtrees requesting an update. This information is        required for every Sync Request.    -   The Sync Packet Id of the last committed Sync Packet. This Id        contains the sequence number or date/time value of the last        committed Sync Packet. This is to request edits that have        occurred since this synchronization. In the absence of this        attribute, it is assumed that the first Sync Packet in the edit        log is the starting point.    -   The Sync Packet Id of the last Sync Packet desired. This is an        optional attribute.    -   The document identifier for the document we are requesting edits        to. In the absence of this attribute, we assume that the request        is for edits to the local document.    -   Whether the document identifier is a public Id or a UUID. This        is basic typing information needed to resolve the document        identifier attribute.    -   A collection of “ts:u” attributes of subtree elements we wish to        exclude from the request. This is optional.

To support tracking changes in collaborative authoring contexts, the“ts:cre” attribute encodes the creation date/time of an instance of anelement derived from the “base” archetype. The “ts:mod” attributeencodes the modification date/time. Modification is defined as a changeto attributes (other than “ts:u”), the generic identifier, the order orexistence of immediate children, and change to any children not enclosedin one or more elements derived from the “base” archetype. Changes tothe “ts:mod” attribute are not themselves considered changes (this rulemay have no consequences since modification does not propagate beyondthe first ancestor element derived from the “base” archetype).

The “ts:cre” and “ts:mod” attribute values are based on system clocksand cannot be trusted as the basis for synchronization, which brings usto synchronization points, described next.

Synchronization Points

We define a “synchronization point” as an event during which a databaseincorporates information from another database, thus instigatingreplication or updating previously replicated information. Each databasehas its own linear address space of synchronization points, preferablyrepresented as strings of decimal digits. Every database will maintain arecord of at least the latest synchronization point with every databasefrom which it imports replicated information. Every database willmaintain a record of at least all synchronization points at whichinformation may have been replicated out.

While it would be useful to keep specific bidirectional records of allsynchronization points, this record keeping may be impractical forcertain databases, for example, a database which serves as a templatefor a large number of other databases or a database on read-only media.Even if this information is always kept, the system must be constructedso as to recover transparently when such export information is lost. Ina presently preferred implementation, databases are not required to keepa record of all databases which have received information replicatedfrom them. Not keeping usage (reference) counts with transactionalintegrity implies a need for a distributed garbage collection solution.Otherwise, one may not know how long to keep synchronization packets.The server environment should provide a mechanism for distributedgarbage collection. This must not interfere with the moment-to-momentoperation of the system at any time.

In our sample schema, the “ts:sy” attribute carries the synchronizationpoint identifier of the first sequence point following the element'screation or modification. Modification is defined as in the definitionof the “ts:mod” attribute. The “ts:sy” attribute is found on the “base”archetype. The type of the value of the “ts:sy” attribute is a stringrepresentation of an integer. The “ts:db” elements under the“synchronization” element in the “context” section hold thesynchronization point log for each database. See the schema of Appendix“A” for details.

Scope of replication can be controlled as well. A database canexplicitly disallow specific data from being replicated outward. Adatabase can explicitly disallow specific data from being replicatedtransitively (i.e., more than one level). Since it is easy to copy data,constraints on replication and transitive replication are not strongsecurity measures. They are more a way of indicating, in an advisorymanner, how the originator of the data wants the data to be handled.Control parameters apply to the transitive closure of a subtree throughcontainment, but not through aliasing or other linking mechanisms. Thisis a case where the physical structure of the database dictates controlsemantics. Items referenced in the structure are not necessarilyprotected by protection of the structure.

Copies created using the services of the present invention preferablycarry a copy attribute that indicates the identity of the originatingelement. The syntax of the copy attribute values is identical to that ofthe “ts:u” attribute value described above. When a subtree is copied, acopy attribute is applied to each element deriving from the “base”archetype, identifying its corresponding source. Changes from otherdatasources are captured using one of a variety of techniques. Examplesare:

-   -   Tracking change during modification in the manner of the        invention    -   Comparison of backing store    -   Query based on modification stamp.    -   Use of database logging facilities.

The present invention also very effectively addresses (data) schemaincompatibilities. A “schema translator” is a software component thatconverts data of one specific schema to data of another specific schema.Each version of each schema component preferably has a publicidentifier. One or more schema translators can be associated with adirected pair of schema component public identifiers. A flag for eachregistered transformer indicates whether the transformation involves aloss of data. Transformer pairs that have been successfully reviewed andtested for lossless round trip are registered as such. “Registered”alludes to the registrar described above with reference to FIG. 3 andfurther described below. Each version of each application registers theschema components it depends upon.

Consistent with the present invention, client-client, client-server andserver-server interactions are all mediated by XML based messaging.(Alternative encodings can be used when both parties can handle them.)Standard encryption and authentication methods can and should be used tomanage these messages. The invention relies on XML and transmission ofother file types. This messaging can be accomplished using a widevariety of transmission techniques, including but not limited to thefollowing protocols, technologies and standards, individually or incombination:

-   -   TCP/IP    -   Hypertext Transport Protocol (http)    -   Secure Hypertext Transport Protocol (https)    -   SOAP    -   E-mail    -   Secure Socket Layer (SSL)    -   Short Message Service (SMS)    -   Cellular Digital Packet Data (CDPD)    -   GSM    -   GPRS

The server environment described above preferably also includes anincident reporting service. This is a service that tracks subscriptionsto events associated with particular resources, and informs subscriberswhen those events occur. Services of this type are used most commonly totrack dependencies between source databases and databases whichreplicate parts of the source databases.

The incident reporting service manages relationships among resourcesknown to the system of the present invention. Database representationsof these relationships are generally redundant, in that the receivingdatabase knows about its relationship with the originating database.(The originating database may also know about the receiving database.)In other words, database relationships are peer to peer, but theincident reporting service facilitates communication between peers whichmay not be active at the same time. The purpose of the incidentreporting service is to facilitate the timely update of databases, butit has no responsibility for actually scheduling tasks. Clients of themessaging service can use the incident reporting service as a sort of“group” mechanism: messages sent to the incident reporting servicereferencing a resource are can be forwarded to each of the subscribersto that resource.

Another component of the server environment in a preferred embodiment isa task allocator (not shown). This is a service that assigns interactivetasks to available computational resources based on suitability topurpose (server load, access to resources, availability of cacheddatabase or session state). The allocator depends upon the locationbroker to identify the location of resources and the performance monitorto determine the load on each of the relevant resources.

Another component of the server environment in a preferred embodiment isa task scheduler (not shown). This is a component that assignscomputational tasks to available computational resources based onpriority, aging, deadlines, load, etc. Typically the tasks handled inthis manner are not in response to a current user request. In order todeliver optimal performance in response to user requests, the inventionmakes provision for accomplishing preparatory tasks in the background ona time available basis. Tasks likely managed in this way by thescheduler include, but are not limited to:

-   -   synchronizing databases    -   creating usage reports    -   optimizing databases    -   garbage collection of unneeded synchronization packets    -   crawling personalized web sites

The task scheduler depends upon the task allocator to actually allocatetasks.

The location broker is component of the invention that can accept anidentifier for a resource and provide means to contact that resource.Resources are not necessarily local to the broker.

A directory of services is a location broker that provides a navigableindex of available services. Location broker services are needed to finddatabase resources in the computing environment of the invention, whereresources are distributed and location is subject to change.

Given a public identifier or system identifier the location brokerprovides access to the resource. In the simplest case, the locationbroker will satisfy a request by posting the URL given in the publicidentifier. This a degenerate case above which the location broker canadd value. For example, the location broker can cache responses.

Registrar

The registrar, as mentioned above, manages metadata to enable theinvention's distributed deployment. Data associations managed by theregistrar include, but are not limited to:

-   -   schema public identifiers with schema representation    -   schema translators with directed pairs of schema public        identifiers, including flag for whether translation loses        information    -   datasource public identifier with datasource declaration    -   servo public identifier with servo declaration    -   each servo public identifier with the public identifiers of the        schemas it uses    -   each servo public identifier with the public identifiers        referencing schema referenced in the opportunity declarations of        the servo

The registrar provides mappings across these associations use standarddatabase techniques. In addition, the registrar calculates besttranslation path (if any) between any two schema public identifiersusing standard graph analysis algorithms.

Synchronizer

The synchronizer (310, 326 in FIG. 3) is a component that usestransaction records, synchronization point identifiers, time stamps,datasource declarations and database instance-specific parameters tomaintain correct database state across a set of related databasesmanaged by the invention. The synchronization point identifier is anidentifier uniquely representing a synchronization point for aparticular database. Recall a synchronization point is the event duringwhich a database incorporates information from another database, thusinstigating replication or updating previously replicated information.

The synchronizer is responsible for generating and processing thesynchronization packets that mediate the propagation of change amongcomponents of the invention. Data source declarations influence thetiming of synchronization by indicating when and how quickly databecomes obsolete. Time stamps are relevant when time-dependent data suchas stock quotes need to be reconciled.

Coordinating XML Stores

The invention's default approach for distributed lock management isoptimistic but centralized (on a per-resource basis). Authority toattempt change is given by the datasource declaration. Change isimplemented through one or more protocols published with the datasourcedeclaration. These protocols can be classified as either low-level “dataoriented” XML modification protocols, such as TSXUL, or higher-level“object oriented” actions which can be schema specific.

There are several levels at which a change can fail:

-   -   Data source does not accept changes: The datasource may choose        not publish a protocol for accepting changes. Such a datasource        is effectively read-only.    -   Individual requesting change does not have authority to make        changes (at all) to the data. This is commonly called        resource-level access control.    -   Individual requesting change does not have authority to make the        specific changes (e.g., some fields are editable, some are not).        In such a case, specification of what can be changed should be        made available as part of the change protocol so that upstream        clients don't lead individuals to attempt changes which will        ultimately fail.    -   An individual's changes conflict with other changes made since        the conflicting sources have a common baseline. For example, two        people change the same text field.

The invention attempts to detect these issues as far upstream aspossible, but the datasource itself must do it's own checking

There are a number of ways a client can deal with “rejected” changes.The last two in the list below are used by the preferred embodiment ofthe invention.

-   -   Transaction managed client aborts transaction, changes never        committed.    -   Client does not apply actual change to its store before        submitting the request. The requested modification continues to        have unofficial status (e.g., modified data in a form).    -   Client has already implemented update but applies “undo” info        saved as part of synchronization point.    -   Client receives update synchronization packets as response,        updates, shows user conflicting information, provides        opportunity to retry.

Replication of data must be carefully managed as well. In accordancewith the invention, a transient database is used, i.e., a database thatexists only for the purpose of messaging.

Databases that are created only for the purpose of transmitting data aretransient: they need not have public IDs because it is not alwaysrequired for them to be publicly addressable. They do have system IDs.Whenever data is replicated the root element(s) of the replicated datacarry a master” attribute which contains the local alias of the master.Even when new elements are created in subtrees that are masteredelsewhere, they are give “ts:u” identifiers as mentioned above for thedatabase in which they are created. In situations where a client that isoriginating edits is in direct communication with the master, the “ts:u”attributes can be normalized to new identifiers scoped to the master.This is useful in situations where it is important to protect theprivacy of the originator of the data. It also reduces the number ofdatabase declarations that need to be created in context/imports.

Managing Dependencies Among Applications and Schema Components

Applications and their underlying schema are expected to change overtime. New capabilities are added, ambiguities are fixed and sometimesapplications are simplified. Since multiple applications may bedepending on different versions of the same schema, the invention mustemploy the schema translation infrastructure to keep everything workingthrough a transition.

The invention's ability to manage schema and schema translation meansthat new schema need never be forced on users unless they wantcapability enabled by the new schema, or enabled by applications thatwork only with the new schema. Each database automatically maintainslists of imported (used) schemas. (Automatic tracking for thedependencies that instance data has on schema).

The scheduling capabilities of the server environment are used toidentify and applications requiring update and taking them through theneeded transformations in a timely manner.

Managing Schema Registered with the Invention

To fully benefit from the integration made possible by the inventionsome human coordination is valuable. On their own, different applicationdevelopers will extend the base schema in multiple incompatible ways. Tosee how this works in practice, consider the hobby of collecting. Thereare some shared characteristics for how collectors operate, but theobjects collected are diverse, as are the sources of information.Everyone involved in stamp collecting needs a common way to describe theartifacts. Individuals and vendors need a way to document theirholdings, offer items for sale and identify items available for purchasefrom others. Information about individual artifacts and issues can comefrom publications, news groups, clubs, commercial websites and websitesof issuing governments. Many of these parties have reason to have aninterest in having their information accessible in a public deploymentof the invention, if the environment has already been well seeded and itis reasonably easy or them to make the necessary extensions.

All that is fine until different people begin extending the system inmutually incompatible ways. For example, two different parties mightextend the schema in different ways to cover the same missing data, saythe name of the designer of a stamp. Now there are some views thatexpect the designer of a stamp to be encoded one way, and some viewsthat expect it to be encoded another way. Neither set of views will beable to show data that is in the encoding expected by the other.Reconciling these differences requires human intervention to establish astandard schema, map the variant schemas to the standard schema, andtransform the views accordingly. The role of “schema editor” is aservice that keeps the system running smoothly by arbitrating thepreferred schema. Third party schema developers can create, using theinvention, the transformers that translate instances between schemas.Throughout this process, each variant of a schema can registered andauthenticated through the processes described above.

It will be obvious to those having skill in the art that many changesmay be made to the details of the above-described embodiments of thisinvention without departing from the underlying principles thereof. Thescope of the present invention should, therefore, be determined only bythe following claims.

1. (canceled)
 2. A computer-implemented, incremental process for executing an application servo on a mobile computing device in a distributed computing system for intermittently networked devices based on a specified set of matching criteria, the process comprising: selecting a servo to provide services, the servo stored in local storage on the mobile computing device, the servo comprising a declaration of a datasource on the mobile computing device, the declaration including or referencing a schema, and a declaration of a view, the declaration including a plurality of transformation rules mapping schema components to abstract interface objects or concrete interface objects; identifying on the mobile computing device, the datasource defined by the declaration of the datasource in the selected servo; initializing on the mobile computing device an execution context tree structure by creating a root node of the context tree associated with an initial transformation rule of the servo; choosing a context of the context tree that satisfies the matching criteria; executing a transformation rule of the servo associated with the chosen context; responsive to said executing step, creating zero or more new child contexts in the context tree, each new child context including content defining a current internal evaluation state of the process; repeating said choosing, executing and creating steps over subsequent transformation rules of the servo until no context satisfies the matching criteria; responsive to changes to the datasource, marking dependent contexts as unverified; choosing a marked context of the context tree; performing a transformation rule of the servo associated with the chosen context; responsive to said executing step, creating zero or more new child contexts in the context tree and removing or modifying zero or more existing child contexts; unmarking the chosen context and marking zero or more dependant contexts as unverified; and repeating said choosing, performing, creating, removing, modifying, unmarking and marking steps over subsequent transformation rules of the servo until no contexts are left marked.
 3. A process according to claim 2 wherein the content of the child context includes: a pointer to an element within the selected servo; and a pointer that identifies a current data context by pointing into a source tree.
 4. A process according to claim 2 wherein the content of the child context includes; a reference to a parent context; an ordered, potentially sparse, list of pointers to zero or more child contexts; and definitions for any symbols introduced by the context.
 5. A process according to claim 2 further including, responsive to said executing and performing steps, creating zero or more child spacers in the context tree representing unmaterialized child contexts; and wherein said choosing a context includes choosing either a context or a spacer.
 6. A process according to claim 5 wherein the context tree is implemented using a relative b-tree structure, and each spacer is reflected in an interior node entry in the relative b-tree structure to facilitate searching unmaterialized contexts.
 7. A process according to claim 2 wherein the b-tree node entry includes a field to track a linear value associated with a graphical display output object.
 8. A process according to claim 2 wherein the process creates and maintains both the context tree and a geometry tree, the geometry tree representing the spatial structure of a predetermined graphical user interface.
 9. A process according to claim 2 wherein the servo is defined using a servo definition language that references XML schema definitions as its core vocabulary.
 10. A process according to claim 9 wherein the servo definition language comprises: application data schema; transformation rules; and opportunity rules.
 11. An interpreter stored in a non-transitory computer-readable medium of a mobile computing device in a distributed computing system, the interpreter for interpreting a servo definition language for defining a distributed application that supports disconnected operation on the mobile computing device, the language comprising: application data schema; transformation rules; transaction rules; transaction handling rules; interface object specifications; opportunity rules to realize automatic extension or integration of servos through opportunity-based linking of an interface component representing an instance of a schema fragment to a template.
 12. An interpreter according to claim 11 further comprising access rules.
 13. An interpreter according to claim 11 wherein the template specifies at least one of a transformation rule, a transaction handling rule and an interface object specification.
 14. An interpreter according to claim 11 and further comprising an abstract interface object definition.
 15. An interpreter according to claim 11 wherein the application data schema comprises an XML-based schema.
 16. An interpreter according to claim 11 defined using XML schema definitions XSD as the core vocabulary.
 17. An interpreter according to claim 11 including a view element for selecting a group of the said transformation rules to define at least a part of an output interface.
 18. An interpreter according to claim 11 including a storage declaration element that enables an author to reserve and name persistent storage on the mobile computing device for use by the servo and any other servos authorized to access the corresponding data, wherein data in the storage on the mobile computing device is synchronized with replica data on a server computing device in the distrubuted computing system.
 19. An interpreter according to claim 18 wherein the storage declaration element includes a locally scoped name for a corresponding storage tree and identifies a schema to which the storage tree must conform. 